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(57) An apparatus and method of managing a virtual 
private network having a set of network devices main- 
tains a network device memory set for storing a set of 
network device identifiers that identifies each of the set 
of network devices. More particularly, a request to join 
the virtual private network is received from a given net- 
work device having a given network device identifierthat 
identifies the given network device. The set of network 
device identifiers then is retrieved from the network de- 
vice memory set to identify all network devices in the set 
of network devices. A notify message then is forwarded 
to each of the set of network devices, and a join mes- 
sage is forwarded to the given network device. The no- 
tify message includes the given network device identifi- 
er, while the join message includes the set of network 
device identifiers. The given network device identifier 
then is stored in the network device memory set. 
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Description 

FIELD OF THE INVENTION 

[0001] The invention generally relates networks and, 
more particularly, the invention relates to managing a 
virtual private network. 

BACKGROUND OF THE INVENTION 

[0002] Although deployed across third party net- 
works, virtual private networks have the look and feel of 
a private network, such as an intranet utilized by a pri- 
vate company. In fact, many currently utilized virtual pri- 
vate networks are deployed across the Internet to pro- 
vide a private network solution at a relatively low cost. 
[0003] A virtual private network ("VPN") often in- 
cludes two or more preconfigured network devices that 
each act as VPN nodes in their VPN. To that end, each 
such network device typically is preconfigured with the 
address of all other network devices to be in their VPN, 
and preselected network routes (hereinafter "tunnels") 
between each of the other network devices in their VPN. 
Byway of example, a given VPN that utilizes the Internet 
may include a first router with its associated local area 
network, and a second router with its associated local 
area network. The first router is preconfigured to have 
the Internet Protocol address of the second router, and 
a set of preselected network tunnels to the second rout- 
er. In a similar manner, the second router is preconfig- 
ured to have the Internet Protocol address of the first 
router, and a set of preselected network tunnels to the 
first router. Accordingly, the two routers and the mem- 
bers of their respective local area networks communi- 
cate in their VPN across the Internet via the preselected 
network tunnels. 

[0004] Problems arise, however, when network devic- 
es (e.g., routers) that are not preconfigured are to be 
added to a VPN that operates in the above described 
manner. Specifically, such network devices cannot be 
added to a VPN unless they are configured with the 
above noted preconfigu ration data. 

SUMMARY OF THE INVENTION 

[0005] In accordance with one aspect of the invention, 
an apparatus and method of managing a virtual private 
network having a set of network devices maintains a net- 
work device memory set for storing a set of network de- 
vice identifiers that identifies each of the set of network 
devices. More particularly, a request to join the virtual 
private network is received from a given network device 
having a given network device identifier that identifies 
the given network device. The set of network device 
identifiers then is retrieved from the network device 
memory set to identify all network devices in the set of 
network devices. A notify message then is forwarded to 
each of the set of network devices, and a join message 



is forwarded to the given network device. The notify 
message includes the given network device identifier, 
while the join message includes the set of network de- 
vice identifiers. The given network device identifier then 
5 is stored in the network device memory set. 

[0006] In response to receipt of the notify message, 
at least one of the set of network devices preferably 
communicates with the given network device to estab- 
lish a communication tunnel with the given network de- 

10 vice. In a similar manner, in response to receipt of the 
join message, the given network device preferably com- 
municates with at least one of the network devices in 
the set of network devices to establish a communication 
tunnel with the at least one of the set of network devices. 

15 Among other data, the request may include a network 
identifier identifying the given virtual private network. In 
alternative embodiments, the total number of network 
devices in the set of network devices may equal zero. 
In such case, the network device memory set may be a 

20 database that is established for the given virtual private 
network in response to receipt of the request. 
[0007] In some embodiments, the apparatus and 
method authenticate the request to confirm the identity 
of the given network device. The request may be re- 

25 ceived from a packet based network, and the network 
identifier may be an Internet Protocol address. Moreo- 
ver, among other data, the join message and notify mes- 
sage may include data identifying the given virtual pri- 
vate network. In some embodiments, the apparatus and 

30 method generate the notify and join messages. 

[0008] A remove message may be received from a re- 
move network device. Once received, all network device 
identifiers again may be retrieved from the network de- 
vice memory set, and a first message may be forwarded 

35 to all network devices identified by the retrieved network 
device identifiers. Each first message may include a re- 
move identifier identifying the remove network device. 
In addition, in response to receipt of the first message, 
at least one of the network devices in the set of network 

40 devices disconnects a communication tunnel between 
the at least one network device and the remove network 
device. A second message that includes the retrieved 
network device identifiers may be forwarded to the re- 
move network device. 

45 [0009] In accordance with another aspect of the in- 
vention, a method of managing a virtual private network 
(having a set of member network devices each identified 
by a device identifier) maintains a storage device with 
the device identifier of each member. The storage de- 

50 vice is updated as network devices are added to and 
removed from the virtual private network. Accordingly, 
in response to receipt of a request to join the virtual pri- 
vate network (from a given network device having a giv- 
en network device identifier and data identifying the vir- 

55 tual private network), a notify message and join mes- 
sage are generated. The notify message has the given 
network device identifier, while the join message has the 
device identifiers in the storage device. The notify mes- 
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sage then is forwarded to each of the set of network de- 
vices, and the join message is forwarded to the given 
network device. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0010] The foregoing and advantages of the invention 
will be appreciated more fully from the following further 
description thereof with reference to the accompanying 
drawings wherein: 

[0011] Figure 1 schematically shows an exemplary 
network arrangement in which illustrative embodiments 
of the invention may be implemented. 
[0012] Figure 2 schematically shows a manager serv- 
er that manages virtual private networks in accordance 
with illustrative embodiments of the invention. 
[0013] Figure 3 schematically shows an illustrative 
database that may be in data storage for storing data 
relating to various VPNs. 

[0014] Figure 4 shows an illustrative process of es- 
tablishing and maintaining a VPN in accordance with il- 
lustrative embodiments of the invention. 
[0015] Figure 5 shows an illustrative process utilized 
by the manager server in figure 2 for removing a router 
from a VPN. 

DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS 

[0016] Figure 1 schematically shows an exemplary 
network arrangement that may be utilized to implement 
a virtual private network ("VPN") configured in accord- 
ance with illustrative embodiments of the invention. 
Specifically, the network 10 includes a plurality of local 
area networks 12 that each communicate with a VPN 
manager server ("manager server 14") via the Internet 
16. The manager server 14 may be a single server, or 
a cluster of cooperating servers. In fact, the manager 
server 14 need not be a part of any VPN. For example, 
the manager server 14 may be utilized as a third party 
service that establishes, maintains, and terminates 
VPNs for any set of network devices (e.g., routers). 
[0017] Each local area network 12 includes one or 
more conventional routers 18 and a plurality of coupled 
clients 20. The clients 20 each may be any type of well 
known network device, such as a personal computer or 
server. Of course, each router 18 includes the logic for 
cooperating with the other network devices (i.e., the oth- 
er routers 18 and the manager server 14) to establish 
VPNs in accordance with illustrative embodiments of the 
invention. 

[0018] In some embodiments, the routers 18 and 
manager server 14 cooperate to establish, maintain, 
and terminate VPNs in a manner that permits routers 1 8 
and other network devices to join VPNs without having, 
in advance, special preconfigured tunnels and special 
preconfigured VPN membership lists. More particularly, 
as discussed in greater detail below, network devices 
joining a specified VPN are given a current list of mem- 



bers of the specified VPN upon joining. Accordingly, 
joining network devices are not required to have the 
identity of all such members preconfigured in their mem- 
ory prior to joining. This permits membership in VPNs 

5 to be dynamically changed with relative ease. Moreover, 
the various tunnels utilized for transmitting data be- 
tween the member network devices can be dynamically 
established by the existing member network devices 
and joining devices at the time that the joining network 

10 devices join the VPN. This enables the member network 
devices to establish optimal tunnels based upon current 
network conditions and thus, not based upon preconfig- 
ured tunnels that may be less efficient. 
[0019] As shown in figure 2, the manager server 14 

15 includes various modulesfor managing the membership 
of any VPN that may be established across the network 
in accord with illustrative embodiments of the invention. 
The manager server 14 may simultaneously manage 
any number of VPNs, such as one VPN, or hundreds of 

20 VPNs. To that end, the manager server 14 includes data 
storage 22 (e.g., a database) for storing information re- 
lating to one or more VPNs, a parser 23 for parsing data 
from received messages, a message generator 24 for 
generating messages identifying members of the vari- 

25 ous VPNs managed bythe manager server 14, and VPN 
logic 26 for managing the various VPNs and retrieving 
data from the database. The manager server 14 also 
includes an input port 28 for receiving data from the In- 
ternet 16, and an output port 30 for forwarding data to 

30 the various routers 18 across the Internet 16. Details of 
the interaction of these manager server modules are 
discussed below with reference to figures 4 and 5. 
[0020] Figure 3 schematically shows a preferred VPN 
database ("database 22a") in the data storage 22. In 

35 particular, the database 22a includes a plurality of lists 
of data that each relate to one VPN. For example, the 
database 22a shown includes data relating to a total of 
Z VPNs that each are managed by the manager server 
14. Each VPN has an associated VPN identification 

40 code, security data relating to the VPN, and a list of net- 
work devices (i.e., routers 18) that are members of the 
specified VPN. Among other things, the security data 
may include authentication data for authenticating rout- 
ers 1 8 attempting to access the VPN, such as encryption 

45 keys an/or passwords. 

[0021] Figure 4 shows an illustrative process utilized 
by the manager server 14 for establishing and maintain- 
ing a VPN in accordance with illustrative embodiments 
of the invention. The process begins at step 400 in which 

50 a request message from a router 18 attempting to join 
a given VPN is received at the input port 28 of the man- 
ager server 14. The request includes the VPN identifier 
identifying the VPN the router 18 is attempting to join, 
and the Internet Protocol address of the router 18. In 

55 addition, the request also may include topology data, or 
authentication data (e.g., a password or an encryption 
key). 

[0022] Upon receipt of the request, the VPN logic 26 



3 



5 



EP 1 093 254 A2 



6 



parses the request to determine the VPN identifier, IP 
address, and the security data (step402). The VPN logic 
26 then determines, at step 404, if the router 18 is per- 
mitted to join the VPN to which membership is request- 
ed. To that end, the VPN logic 26 may access the data- 
base 22a to determine if the security data in the request 
matches the security data in the database 22a. For ex- 
ample, a password may be compared to determine if 
access to the VPN is permitted. As a further example, 
symmetrical and asymmetrical keys may be utilized with 
conventional encryption methods for authentication pur- 
poses. The process ends if the router 18 is not authen- 
ticated. In such case, the message generator 24 may 
generate and forward a denial message to the request- 
ing router 18 indicating that such router 18 cannot join 
the requested VPN. 

[0023] If the VPN logic 26 determines at step 404 that 
the router 18 is permitted to join a VPN, then the process 
continues to step 406 in which the VPN logic 26 deter- 
mines if the VPN to which access is requested is cur- 
rently executing (i.e., it is determined if such VPN ex- 
ists). To that end, the VPN identifier in the request is 
compared to the VPN identifiers in the database 22a. If 
no such VPN is found in the database 22a, then the 
process continues to step 408 in which a new database 
22a for the requested VPN is initialized. The new data- 
base 22a preferably is added to the existing database 
22a as another VPN entry (i.e., another list in the data- 
base 22a). Alternatively, the new database 22a is sep- 
arate from the existing database 22a. The new database 
22a may be initialized to include the VPN identifier and 
Internet Protocol address (of the requesting router) 
parsed from the request. In addition, the new database 
22a also may include security data parsed from the re- 
quest. Accordingly, the security data parsed from the re- 
quest is utilized to authenticate subsequent network de- 
vices attempting to access the noted VPN. 
[0024] In alternative embodiments, the managerserv- 
er 14 cannot initialize VPNs that do not have an existing 
entry in the database 22a. In such case, if there is no 
match, the manager server 14 may generate and for- 
ward a rejection message to the requesting router 18. 
The rejection message acknowledges receipt of the join 
request, but indicates that the request to join the VPN 
was rejected. 

[0025] Returning to step 406, if it is determined that 
the request VPN does in fact exist and has at least one 
member router 18, then the process continues to step 
410 in which various messages are generated for the 
member routers 18 and the joining router 18. More par- 
ticularly, the VPN logic 26 provides the message gener- 
ator 24 with the Internet Protocol address of the joining 
router 18, the Internet Protocol address of the member 
routers 18 already in the VPN, and the VPN identifier. 
The message generator 24 responsively generates a 
notify message for the member routers 18, and a join 
message for the joining router 18. The notify message 
includes the Internet Protocol address of the joining 



router 1 8, the VPN identifier, and a command requesting 
that the router 18 receiving the message form a tunnel 
between it and the joining router 18. In a similar manner, 
the join message includes the Internet Protocol address 
5 of all member routers 18 (i.e., at least one), the VPN 
identifier, and a command requesting that the joining 
router 18 form a tunnel between it and all other member 
routers 18 identified in the message. 
[0026] Once the messages are generated, they are 

10 forwarded to the output port 30 and consequently, trans- 
mitted to the appropriate devices via the Internet 16 
(step 412), thus ending the process. Accordingly, a copy 
of the notify message is transmitted to all routers 1 8 that 
are existing members of the VPN, while the join mes- 

15 sage is transmitted to the joining router 18. 

[0027] Upon receipt, a receiving router 18 parses the 
notify message to ascertain the VPN identifier and In- 
ternet Protocol address of the joining router 18. In re- 
sponse, the receiving router 1 8 contacts the joining rout- 

20 er 18 via a conventional router protocol to form a com- 
munication tunnel. Among others, such protocols may 
include the Routing Information Protocol ("RIP"), the 
Border Gateway Protocol ("BGP"), and the Open Short- 
est Path First ("OSPF"). In a similar manner, the joining 

25 router 18 parses the received join message to ascertain 
the VPN identifier and the Internet Protocol address of 
each router 18 in the VPN. The joining router 18 then 
also contacts the other routers 18 via a conventional 
router protocol to form the communication tunnel in ac- 

30 cord with conventional processes. In illustrative embod- 
iments, these tunnels do not necessarily include the 
manager server 14 and thus, are relatively direct tunnels 
between routers 18. In illustrative embodiments, a tun- 
nel includes the manager server 14 only if it is the most 

35 efficient tunnel. 

[0028] While forming the tunnels in a VPN, cooperat- 
ing routers 18 may utilize various security protocols to 
ensure that data in the VPN is not compromised during 
data transmission. One such protocol is the Internet Pro- 

40 tocol security protocol ("IPsec"), which is a well known 
IETF (Internet Engineering Task Force) standard defin- 
ing certain requirements for establishing a secure elec- 
tronic channel with a session key. One known security 
method that is used by the IPsec protocol that may be 

^5 utilized in illustrative embodiments is known as the 
"Rivest, Shamir, and Adleman cryptography method" 
(RSA cryptography method). 

[0029] VPNs may be formed in any desired topology. 
To that end, the initial router 18 that forms a VPN may 

50 include data relating to topology in the initial request to 
the manager server 14. The manager server 14 conse- 
quently may store such information in the database 22a, 
and include such information to subsequent notify and 
join messages. In illustrative embodiments, any well 

55 known topology may be used, such as full mesh topol- 
ogy, ring topology, star topology, or any combination 
thereof. For example, an initial router 18 of a given VPN 
may designate itself as a centra! router 18 in a star to- 
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pology. Accordingly, the database 22a in such example 
includes topology data indicating that the given VPN uti- 
lizes a star topology, and that the initial router 18 is the 
central router 18. Such data therefore is included in all 
subsequent join and notify messages. 
[0030] Figure 5 shows an illustrative process utilized 
by the manager server 14 for removing a router 18 from 
a given VPN: The process begins at step 500 in which 
a termination message is received at the input port 28. 
The termination message is generated and forwarded 
to the manager server 14 from a router 18 requesting 
that it be removed from the given VPN. In illustrative em- 
bodiments, the termination message includes the Inter- 
net Protocol address of the router 18 requesting to be 
terminated (terminated router 18T), the VPN identifier 
of the given VPN, and data indicating that the terminated 
router 18T is to be terminated. 

[0031] Upon receipt of the termination message, the 
VPN logic 26 accesses the database 22a to determine 
which routers 1 8 (if any) are members of the VPN at that 
time (step 502). The process continues to step 504 in 
which the Internet Protocol addresses of all members of 
the given VPN are retrieved from the database 22a, and 
then added to a newly generated first termination mes- 
sage. In addition to the Internet Protocol addresses, the 
first termination message also includes the VPN identi- 
fier of the given VPN. The message generator 24 also 
responsively generates a second termination message 
that includes the Internet Protocol address of the termi- 
nated router 18T, and the VPN identifier of the given 
VPN. 

[0032] Once the first and second termination messag- 
es are generated, they are forwarded to the output port 
30 for transmission to the respective routers 18 (step 
506). In particular, the first termination message is trans- 
mitted to the terminated router 18T, and the second ter- 
mination message is forwarded to each of the routers 
1 8 that are members of the given VPN at that time. After 
the messages are transmitted, the Internet Protocol ad- 
dress of the terminated router 18T is removed from the 
database 22a for the given VPN. 

[0033] Upon receipt of the first termination message, 
the terminated router 1 8T communicates with each rout- 
er 18 identified in the message to disconnect any com- 
munication tunnels established for the given VPN be- 
tween it and such other router(s) 18 (step 508). In a sim- 
ilar manner, upon receipt of the second termination mes- 
sage, a receiving router 18 communicates with the ter- 
minated router 18T to disconnect any communication 
tunnels established for the given VPN between it and 
the terminated router 1 8T Conventional tunnel termina- 
tion methods may be utilized to terminate inter-router 
tunnels. 

[0034] As known in the art, routers 18 in a VPN can 
malfunction and thus, lose all communication tunnels 
with other routers 18 in its VPN. Moreover, a router 18 
can be removed from its VPN without the interaction de- 
scribed above with reference to figure 5 and similarly 



stop communicating with other routers 18 in the VPN. 
When a router 18 is no longer communicating in one of 
these manners, however, the manager server 14 is not 
notified and thus, maintains such router's Internet Pro- 

5 tocol address in its database 22a. This can cause prob- 
lems when subsequent routers 18 attempt to contact the 
router 18 that is causing the problem. 
[0035] This problem may be solved, however, by in- 
cluding a polling mechanism on each router 18 and/or 

10 the manager server 14. Specifically, the polling mecha- 
nism on each router 18 may transmit a status message 
to the manager server 14 once during each preselected 
time interval. This interval may be configured to be any 
time frame, such as every tenth of a second, every sev- 

15 eral hours, or any other periodic interval. Upon receipt 
of a status message from a given router 18, the manager 
server 14 may generate and transmit an acknowledg- 
ment of receipt of the status message. Accordingly, the 
manager server 14 has a poll timer that is set to count 

20 down during each given time interval. If a status mes- 
sage is not received from any of the routers 18 {i.e., a 
"non-responsive router 18") in the given VPN during one 
given time interval, then the Internet Protocol address 
of the non-responsive router 18 is deleted from the da- 

25 tabase 22a in the manager server 14. The manager 
server 14 then generates and transmits a second mes- 
sage (described above with reference to figure 5) to 
each of the routers 18 in the VPN, causing them to ter- 
minate communication with the non-responsive router 

30 18. 

[0036] Alternatively, instead of a polling mechanism 
between the manager server 14 and the routers 18, 
each router 18 merely can forward a message to the 
manager server 14 each time such router 1 8 detects that 

35 one of the routers 18 in its VPN is not responsive. The 
message includes the VPN identifier and the Internet 
Protocol address of the non-responsive router 1 8. Upon 
receipt of the message, the manager server 14 then can 
attempt to contact the non-responsive router 18 to con- 

40 firm that it, in fact, is not responding. If confirmed, then 
its Internet Protocol address is deleted from the data- 
base 22a. The manager server 14 then generates and 
transmits a second message (described above) to each 
of the routers 18 in the VPN, causing them to terminate 

45 communication with the non-responsive router 18. 

[0037] Illustrative embodiments of the invention may 
be implemented in any conventional computer program- 
ming language. For example, illustrative embodiments 
may be implemented in a procedural programming lan- 

50 guage (e.g., "C") or an object oriented programming lan- 
guage (e.g., "C++" or "JAVA"). Alternative embodiments 
of the invention may be implemented as prepro- 
grammed hardware elements (e.g., application specific 
integrated circuits or digital signal processors), or other 

55 related components. 

[0038] Alternative embodiments of the invention also 
may be implemented as a computer program product 
for use with a computer system. Such implementation 
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may include a series of computer instructions fixed ei- 
ther on a tangible medium, such as a computer readable 
media (e.g., a diskette, CD-ROM, ROM, or fixed disk), 
or transmittable to a computer system via a modem or 
other interface device, such as a communications 5 
adapter connected to a network over a medium. The 
medium may be either a tangible medium (e.g., optical 
or analog communications lines) or a medium imple- 
mented with wireless techniques (e.g., microwave, in- 
frared or other transmission techniques). The series of 10 
computer instructions preferably embodies all or part of 
the functionality previously described herein with re- 
spect to the system. Those skilled in the art should ap- 
preciate that such computer instructions can be written 
in a number of programming languages for use with 15 
many computer architectures or operating systems. 
Furthermore, such instructions may be stored in any 
memory device, such as semiconductor, magnetic, op- 
tical or other memory devices, and may be transmitted 
using any communications technology, such as optical, 20 
infrared, microwave, or other transmission technolo- 
gies. It is expected that such a computer program prod- 
uct may be distributed as a removable medium with ac- 
companying printed or electronic documentation (e.g., 
shrink wrapped software), preloaded with a computer 25 
system (e.g., on system ROM or fixed disk), or distrib- 
uted from a server or electronic bulletin board over the 
network (e.g., the Internet 16 or World Wide Web). 
[0039] Although various exemplary embodiments of 
the invention have been disclosed, it should be apparent 30 
to those skilled in the art that various changes and mod- 
ifications can be made that will achieve some of the ad- 
vantages of the invention without departing from the true 
scope of the invention. These and other obvious modi- 
fications are intended to be covered by the appended 35 
claims. 



Claims 

40 

1 . A method of managing a virtual private network, the 
method comprising: 

receiving a request to join a given virtual private 
network having a set of network devices, the 45 
request being received from a given network 
device having a given network device identifier 
that identifies the given network device; 
retrieving, from a network device memory set, 
a set of network device identifiers that identify 50 
all network devices in the set of network devic- 
es; 

forwarding a notify message to each network 
device in the set of network devices, the notify 
message including the given network device 55 
identifier; 

forwarding a join message to the given network 
device, the join message including the set of 



network device identifiers; and 

storing, in the network device memory set, the 

given network device identifier. 

2. A method of managing a virtual private network hav- 
ing a set of member network devices, each member 
network device being identified by a device identifi- 
er, the method comprising: 

maintaining a storage device having the device 
identifier of each member of the set of network 
devices, the storage device being updated as 
network devices are added to and removed 
from the virtual private network; 
receiving a request to join the virtual private 
network, the request being received from a giv- 
en network device having a given network de- 
vice identifier and data identifying the virtual pri- 
vate network; 

generating a notify message having the given 
network device identifier; 
generating a join message having the device 
identifiers in the storage device; 
forwarding the notify message to each of the 
set of network devices; and 
forwarding the join message to the given net- 
work device. 

3. The method as defined by claim 1 or 2 wherein in 
response to receipt of the notify message, at least 
one of the set of network devices communicates 
with the given network device to establish a com- 
munication tunnel with the given network device. 

4. The method as defined by any preceding claim 
wherein in response to receipt of the join message, 
the given network device communicates with at 
least one of the network devices in the set of net- 
work devices to establish a communication tunnel 
with the at least one of the set of network devices. 

5. The method as defined by any preceding claim 
wherein the request includes a network identifier 
identifying the given virtual private network. 

6. The method as defined by any preceding claim 
wherein the total number of network devices in the 
set of network devices equals zero, the network de- 
vice memory set being a database that is estab- 
lished for the given virtual private network in re- 
sponse to receipt of the request. 

7. The method as defined by any preceding claim 
wherein the request is received from a packet 
based network. 

8. The method as defined by any preceding claim fur- 
ther comprising: 
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authenticating the request to confirm the iden- 
tity of the given network device. 

9. The method as defined by any precdeding claim 
wherein each network identifier is an Internet Pro- 5 
tocol address. 

10. The method as defined by any preceding claim fur- 
ther comprising: 

10 

receiving a remove message from a remove 
network device; 

retrieving all network device identifiers from the 
network device memory set; and 
forwarding a first message to all network devic- 15 
es identified by retrieved network device iden- 
tifiers, each first message including a remove 
identifier identifying the remove network de- 
vice. 

20 

11. The method as defined by claim 10 wherein in re- 
sponse to receipt of the first message, at least one 
of the network devices in the set of network devices 
disconnects a communication tunnel between the 

at least one network device and the remove network 25 
device. 

12. The method as defined by claim 10 or 11 further 
comprising: 

forwarding a second message to the remove 30 
network device, the second message including the 
retrieved network device identifiers. 

13. The method as defined by any preceding claim 
wherein the join message and notify message in- 35 
elude data identifying the given virtual private net- 
work. 

14. The method as defined by any preceding claim fur- 
ther comprising: 40 

generating the notify message and the join 
message. 

1 5. A computer program comprising computer program 
code means for performing all the steps of any pre- 45 
ceding claim when said computer is run on a com- 
puter. 

16. A computer program as claimed in claim 1 5 embod- 
ied on a computer readable medium. so 

17. An apparatus for managing a virtual private net- 
work, the apparatus comprising: 

an input that receives a request to join a given 55 
virtual private network having a set of network 
devices, the request being received from a giv- 
en network device having a given network de- 



vice identifier that identifies the given network 
device; 

data storage for storing a set of network device 
identifiers that identify all network devices in the 
set of network devices; 

a message generator that generates a notify 
message and a join message, the notify mes- 
sage including the given network device iden- 
tifier, the join message including the set of net- 
work device identifiers; 

a request parser that parses the request to de- 
termine the given network device identifier for 
storage in the data storage; and 
an output that forwards one copy of the notify 
message to each network device in the set of 
network devices, the output also forwarding the 
join message to the given network device. 

18. The apparatus as defined by claim 17 wherein in 
response to receipt of the notify message, at least 
one of the set of network devices communicates 
with the given network device to establish a com- 
munication tunnel with the given network device. 

19. The apparatus as defined by claim 17 or 18 wherein 
in response to receipt of the join message, the given 
network device communicates with at least one of 
the network devices in the set of network devices 
to establish a communication tunnel with the at least 
one of the set of network devices. 

20. The apparatus as defined by any one of claims 17 
to 19 wherein the request includes a network iden- 
tifier identifying the given virtual private network. 

21. The apparatus as defined by any one of claims 17 
to 20 wherein the total number of network devices 
in the set of network devices equals zero, the data 
storage including a database that is generated for 
the given virtual private network in response to re- 
ceipt of the request. 

22. The apparatus as defined by any one of claims 17 
to 21 wherein the request is received from a packet 
based network 

23. The apparatus as defined by any one of claims 17 
to 22 further comprising: 

an authentication module operatively coupled 
with the input, the authentication module authenti- 
cating the request to confirm the identity of the given 
network device. 

24. The apparatus as defined by any one of claims 17 
to 23 wherein each network identifier is an Internet 
Protocol address. 

25. The apparatus as defined by any one of claims 17 
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to 23 wherein the input receives a remove message 
from a remove network device, the remove network 
device being one of the set of network devices, the 
apparatus further comprising: 

5 

retrieval logic that retrieves all network device 
identifiers from the network device memory set; 
and 

a remove message generator operatively cou- 
pled with the retrieval logic, the removal mes- 10 
sage generator generating a first message hav- 
ing a remove identifier identifying the remove 
network device, the output forwarding the first 
message to all network devices identified by re- 
trieved network device identifiers. 15 

26. The apparatus as defined by claim 25 wherein in 
response to receipt of the first message, at least one 
of the network devices in the set of network devices 
disconnects a communication tunnel between the 20 
at least one network device and the remove network 
device. 

27. The apparatus as defined by claim 25 or 26 wherein 

the remove message generatorgenerates a second 25 
remove message that is forwarded to the remove 
network device, the second remove message in- 
cluding the retrieved network device identifiers. 

28. The apparatus as defined by any one of claims 17 30 
to 27 wherein the join message and notify message 
include data identifying the given virtual private net- 
work. 

29. A method of managing a virtual private network, the 35 
method comprising: 

a given network device transmitting a request 

to join the virtual private network having a set 

of network devices, the given network device 40 

having a given network device identifier that 

identifies the given network device; 

retrieving, from a network device memory set, 

a set of network device identifiers that identify 

all network devices in the set of network devic- 45 

es; 

forwarding a notify message to each network 
device in the set of network devices, the notify 
message including the given network device 
identifier; so 
forwarding a join message to the given network 
device, the join message including the set of 
network device identifiers; and 
storing, in the network device memory set, the 
given network device identifier. 55 

30. The method as defined by claim 29 further compris- 
ing: 



receiving the notify message; 
retrieving the given network device identifier 
from the received notify message; and 
establishing a communication tunnel to the giv- 
en network device after the given network de- 
vice identifier is retrieved. 
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(57) An apparatus and method of managing a virtual 
private network having a set of network devices main- 
tains a network device memory set for storing a set of 
network device identifiers that identifies each of the set 
of network devices. More particularly, a request to join 
the virtual private network is received from a given net- 
work device having a given network device identifier that 
identifies the given network device. The set of network 
device identifiers then is retrieved from the network de- 
vice memory set to identify all network devices in the set 
of network devices. A notify message then is forwarded 
to each of the set of network devices, and a join mes- 
sage is forwarded to the given network device. The no- 
tify message includes the given network device identifi- 
er, while the join message includes the set of network 
device identifiers. The given network device identifier 
then is stored in the network device memory set. 
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